Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display node 75% view submenus #64121

Merged
merged 81 commits into from
May 18, 2020
Merged

Display node 75% view submenus #64121

merged 81 commits into from
May 18, 2020

Conversation

bkimmel
Copy link
Contributor

@bkimmel bkimmel commented Apr 21, 2020

Summary

This PR adds submenu options to Resolver nodes according to the mocks supplied below.

Notes:

  1. Combined the two menu host buttons into 1 more general component. This makes the code easier to read (1 component instead of 2) and more flexible. ( https://github.com/elastic/kibana/pull/64121/files#diff-b18117271821fdd985eed1e1c4fd749fR75 )
  2. During development, it was noted that the EUI components we are using conflict with the mocks in a few places (e.g. divider lines between options). Where there are conflicts, we are generally planning to break towards the EUI component for consistency with the rest of the Kibana ecosystem. We'll make minimal non-obtrusive adjustments like ( https://github.com/elastic/kibana/pull/64121/files#diff-b18117271821fdd985eed1e1c4fd749fR482 ) for integration with the comprehensive design.
  3. After conversation with the team, we decided that as a short-term measure to allow demo/testing we're going to "spool" all the related event stats from the backend. This obviously will not work long-term for production, as it defeats the purpose of limiting/paging the /related API. Issue: https://github.com/elastic/endpoint-app-team/issues/379
  4. Type information was added to provide a basic shape for the way related data will be tendered to the Resolver ( 36fe414 ).
  5. After further discussion with ( @james-elastic @jonathan-buttner @kqualters-elastic ) a decision was reached to reverse course on Populate scope with country name, not only country codes. #3 in favor of delaying the request for related event info until the submenu is opened (with an interstitial loading state being presented in place of the submenu items with counts). See discussion on issue ( https://github.com/elastic/endpoint-app-team/issues/379 ) for details.
  6. Reducing the stats as a Map<ResolverEvent, StatsInfo> into DataState . Should be relatively fast to update and retrieve, and easy to remove (I've marked a few placed with comments indicating what can be excised easily) when the underlying issue forcing this workaround is resolved. Planning to have the selector merge the Map on top of the waiting Symbols for each result.
  7. Requested pull of [ https://github.com/add related event generation to ancestor nodes (fixes a bug) #64950 ] to fix problem with related event generation for "ancestor" nodes.
  8. Ancestor nodes problem is fixed
  9. Completed the circuit from the API through the middleware => reducer => selector for a possible demo.
  10. Fixed up as unknown as types in middleware here ( 4ad185d#diff-047733952e6965542d27766fbd28864bL102 )
    11 ) Cleanup: moved the submenu to its own component file, added actions to be handled later for related alert/event requests.
  11. Added test coverage for related event selectors and created an issue to explore reinforcing the test suite further ( https://github.com/elastic/endpoint-app-team/issues/418 ).
  12. [As of 5/18/20] This PR stands with the requisite 2 eng and 1 design approvals. All comments have been adjusted for in commits and all outstanding questions answered.

Screenshots

current:
resolver_relateddemo

Mocks

MOCKS ONLY - THESE ARE HERE FOR DESIGN TO REFERENCE
image
MOCKS ONLY - THESE ARE HERE FOR DESIGN TO REFERENCE

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@bkimmel bkimmel added Feature:Endpoint Elastic Endpoint feature Feature:Resolver Security Solution Resolver feature labels Apr 27, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/endpoint-app-team (Feature:Endpoint)

@bkimmel bkimmel changed the title cleanup: move submenus into a general component Display node 75% view submenus Apr 28, 2020
* about a particular subject's related events
*/
export interface RelatedEventDataEntry {
relatedEvents: Array<{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why does this type have a relatedEvents key? In other words, why not:

export type RelatedEventDataEntry = Array<{relatedEvent: ResolverEvent;
    relatedEventType: string;
}>;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought this would make the logic/types/etc. easier to integrate after the PR that fixes the underlying issue (which is currently under review) lands. I'm open to changing it if you feel it would make this more readable.

export interface RelatedEventDataEntry {
relatedEvents: Array<{
relatedEvent: ResolverEvent;
relatedEventType: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If relatedEventType is calculated from ResolverEvent, why is this field needed? Couldn't the code that handles this action could just call eventType(relatedEvent)? This way, the action couldn't have a relatedEventType that was incorrect based on its relatedEvent, and the action would be more normalized.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The overall idea was to make it easier to read when the stats/counts get compiled. At one point this was covered by the union of possible types (which I removed at your request in an earlier commit), but I think I see what you mean there. I made an attempt at putting a more precise description around relatedEventType there. Is that OK, or should I just pull it off altogether?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

x-pack/plugins/endpoint/common/models/event.ts Outdated Show resolved Hide resolved
@bkimmel
Copy link
Contributor Author

bkimmel commented May 18, 2020

@oatkiller I believe all your suggestions have been implemented and I put answers to the balance of questions. Thank you for the review and please let me know if there are more changes to suggest or questions I can answer. 🙇

if (statsMap) {
const currentStatsMap = new Map(statsMap);
const [resolverEvent] = action.payload;
currentStatsMap.set(resolverEvent, new Error('error requesting related events'));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the error message being shown to the user? If not, I think having it in the code is confusing. If so, it should be translated, and it should probably be defined in the view part of the app.

/**
* State for `data` reducer which handles receiving Resolver data from the backend.
*/
export interface DataState {
readonly results: readonly ResolverEvent[];
isLoading: boolean;
hasError: boolean;
resultsEnrichedWithRelatedEventInfo?: Map<ResolverEvent, RelatedEventDataResults>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since resultsEnrichedWithRelatedEventInfo is optional, all the code that deals w/ it checks for its presence. When reading the code, I have to consider what would happen if the value is missing. When writing comprehensive tests, we would also have to account for scenarios where the value is missing.

However, the implementation always provides the value. If some code is written like:

if (resultsEnrichedWithRelatedEventInfo) {
} else {
  // imagine code here
}

Then any code in the else block is in fact dead code, as resultsEnrichedWithRelatedEventInfo isn't really optional. In the future, developers reading and maintaining this code will have to figure out that all these checks are pointless. They will have to figure out that the value isn't really optional. They may be confused, and think that the model is more complex than it is. They may assume that this value is optional, and that all code needs to deal w/ that fact.

I think for these reasons, you should mark the field as non-optional.

@bkimmel
Copy link
Contributor Author

bkimmel commented May 18, 2020

@oatkiller

Is the error message being shown to the user? If not, I think having it in the code is confusing. If so, it should be translated, and it should probably be defined in the view part of the app.

It was only intended to represent an error to the reader/debugger. I've adjusted per your recommendation ( 9e07c11 ) and in the future, I'll avoid using Errors to represent errors to avoid confusion.

@bkimmel
Copy link
Contributor Author

bkimmel commented May 18, 2020

@oatkiller

I think for these reasons, you should mark the field as non-optional.

I see your point - removing that allowed a bit of boilerplate to be taken out as well which I think, on balance, outweighs any benefits I was imagining about creating some arbitrary separation around that piece of state.

Fixed in ( 002d631 )

Copy link
Contributor

@oatkiller oatkiller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for addressing my complaints. Excited to see this in action

@bkimmel
Copy link
Contributor Author

bkimmel commented May 18, 2020

@oatkiller Thank you for taking the time to review. This PR stands with 2 engineering approvals ( yourself and @kqualters-elastic ) and 1 design ( @lindseypoli ). Hoping to merge soon, but I'll defer a bit to see if anyone has additional feedback.

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@bkimmel bkimmel merged commit 1b1a0f4 into elastic:master May 18, 2020
@bkimmel bkimmel deleted the resolver/lay-in-submenu-options branch May 18, 2020 21:34
gmmorris added a commit to gmmorris/kibana that referenced this pull request May 19, 2020
* master: (24 commits)
  [APM] agent config 'profiling_inferred_spans_min_duration' default value is '0ms' but the min value in the field is '1ms' (elastic#66886)
  [Canvas] Fix flaky custom element functional tests (elastic#65908)
  Fix IE specific flexbox min-height issue (elastic#66555)
  [Discover] Unskip doc link functional test (elastic#66884)
  Index pattern management to Kibana platform (elastic#65026)
  Warning and link to support matrix for IE11 (elastic#66512)
  [Reporting] Consolidate Server Type Defs, move some out of Legacy (elastic#66144)
  [SIEM] [Maps] Fixes Network Map empty tooltip (elastic#66828)
  [Endpoint] Encode the index of the alert in the id response (elastic#66919)
  [services/testSubjects] reduce retry usage, add waitForEnabled (elastic#66538)
  [DOCS] Identifies cloud settings for APM (elastic#66935)
  [SIEM][CASE] Fix configuration's page user experience (elastic#66029)
  Resolver: Display node 75% view submenus (elastic#64121)
  [SIEM] Cases] Capture timeline click and open timeline in case view (elastic#66327)
  [APM] Lowercase agent names so icons work (elastic#66824)
  [dev/cli] add support for --no-cache (elastic#66837)
  [Ingest Manager] Better handling of package installation problems (elastic#66541)
  [ML] Enhances api docs for modules endpoints (elastic#66738)
  dont hide errors (elastic#66764)
  [RFC] Global search API (elastic#64284)
  ...
@@ -42,7 +42,7 @@ export const dataReducer: Reducer<DataState, ResolverAction> = (state = initialS
if (statsMap) {
const currentStatsMap = new Map(statsMap);
const resolverEvent = action.payload;
currentStatsMap.set(resolverEvent, new Error('error requesting related events'));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📏 Don't: Use Errors to represent errors. Do: Use a string or an object

@@ -184,7 +184,7 @@ export interface DataState {
readonly results: readonly ResolverEvent[];
isLoading: boolean;
hasError: boolean;
resultsEnrichedWithRelatedEventInfo?: Map<ResolverEvent, RelatedEventDataResults>;
resultsEnrichedWithRelatedEventInfo: Map<ResolverEvent, RelatedEventDataResults>;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📏 Don't: Mark things as optional (even if it seems they could/should be) unless you have code that uses them that way. Do: Mark most things as required in most cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Endpoint Elastic Endpoint feature Feature:Resolver Security Solution Resolver feature release_note:skip Skip the PR/issue when compiling release notes v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants